1. Field
This disclosure is generally related to named data networking (NDN). More specifically, this disclosure is related to a multi-publisher routing protocol for forwarding Interests to a plurality of publishers associated with a name prefix specified by the Interest.
2. Related Art
In custodian-based routing, a node that is an authoritative source for a namespace creates two bindings: one binding from the namespace to an identifier for the node; and another binding from the node's identifier to one or more network addresses for the node. Other network nodes can cache data in the same namespace, and can return this cached data to satisfy an Interest to this namespace. However, they are not authoritative sources for the namespace, so they cannot create the binding to the namespace, such as by advertising themselves as a source for the namespace.
To make matters worse, in custodian-based routing, an authoritative source floods an advertisement for a namespace over the network, such as by using the CCN sync protocol. This allows the network peers to know all the bindings in the computer network. However, managing all namespace-to-device bindings across all nodes in a computer network does not scale well when namespaces have a large set of authoritative sources, especially as some of these authoritative sources may only be sources for short periods of time.
In link-state advertising, a publisher advertises a set of names that map to the publisher's node, and advertises the connectivity of the publisher's node. For example, a publisher with a node “z” may advertise a set of names {“/sweet”, “tart”}→z, and a node connectivity z→{w, x}. There are two common versions of LSA: Optimized Link State Routing Protocol (OLSR), and Named-data Link State Routing Protocol (NLSR). NLSR performs LSA by specifying adjacency information (e.g., a→{(a,b), (a,c), c→{(c,d), (c,a)}), and specifying content available from each node (e.g., a→{ci, cj}, d→{cj}). Hence, a node p adjacent to nodes {b, d} can obtain cj from node d, and a node b adjacent to nodes {a, d, p} can obtain cj from node a or node d. The link state advertisements are written as content centric networking (CCN) content objects, and are synchronized using the CCN sync protocol between the nodes. Hence, NLSR requires using CCN for routing messages across the network. Also, NLSR suffers from similar scalability issues to custodian-based routing, given that NLSR creates a mapping of names to nodes, and advertises node addresses.
OLSR, on the other hand, uses its own messaging format between nodes. OLSR does not require using CCN sync to exchange messages between network nodes. For example, OLSR uses its own messaging format to carry information about the names, instead of sending out information about IP addresses. Also, OLSR supports one path to nearest content. For example, the network nodes can flood their content information across the network. Each node receives a digest of the content provided by the other nodes, and connectivity information for the other nodes. Hence, each node can perform Dijkstra's algorithm to compute the shortest paths to nodes and to content. These nodes can also determine other possible paths by deleting a link for this shortest path, and recomputing a second-shortest path using the remaining network graph. The end result is that the network node can determine various shortest paths to a named content object.
Unfortunately, the above-mentioned routing protocols require all publishers to flood the network with their information. For example, multiple network nodes may each generate different content for a given namespace. In order for network clients to be able to obtain content from these various publishers, each of these publishers needs to flood the network with information that maps them to the namespace. This allows an Interest message from a network client to reach any of the publishers in the network. However, flooding the network with information from every publisher in the network can require the network nodes to include an undesirably large repository of namespace-to-device mappings. Also, each time a publisher enters or leaves a namespace, the publisher and the other network nodes will need to flood changes to the namespace-to-device mappings to reflect the publishers that have entered or left the network.